A virtual private network (VPN) is a way to use a public network infrastructure, such as the Internet, to provide remote offices or individual users with secure access to their organization's network. A virtual private network may be contrasted with an expensive system of owned or leased lines that can only be used by one organization. One goal of a VPN is to provide the organization with the same capabilities, but at a much lower cost.
A VPN works by using the shared public infrastructure while maintaining privacy through security procedures and tunneling protocols such as the Layer Two Tunneling Protocol (L2TP). In effect, the protocols, by encrypting data at the sending end and decrypting it at the receiving end, send the data through a “tunnel” that cannot be “entered” by data that is not properly encrypted. An additional level of security involves encrypting not only the data, but also the originating and receiving network addresses.
Older tunneling protocol and encryption protocol has limitation regarding network address translation, firewall, management, and control of policy. So, people started using secure socket layer (SSL) based VPN, which uses TCP/IP as network medium to transfer the secure data over Internet to the private network. However, the SSL based Virtual Private Networks (VPN) implement application layer security (layer 5 and above) at layer 3. Security protocols above layer 4 allow the applications to have knowledge of these policies, which are otherwise transparent at layer 3. The current VPN implementation allows fat clients such as, for example, email, ftp, web browsers, telnet etc. to have secure access to subnets behind a VPN SSL gateway/firewall. The current implementation employs TCP-over-TCP. The IP packets (with TCP payload) are looped back for SSL processing. The SSL writes happen over a TCP socket. As a result, the application data goes over a TCP-over-TCP connection.
Unfortunately, the TCP-over-TCP implementation does not efficiently handle the TCP traffic over the secure tunnel. The requirements of the high performance VPN solution are not met by a TCP-over-TCP implementation because a protocol ensuring reliability (TCP) is riding over a reliable protocol (TCP). The TCP-over-TCP implementation is also not very graceful and has an inherent design issue: if the innermost TCP link suffers frequent packet loss, the lower layer TCP queues up a retransmission and increase its timeouts. Since the connection is blocked for this amount of time, the upper layer (i.e. payload) TCP won't get a timely ACK, and will also queue a retransmission. Because the timeout is still less than the lower layer timeout, the upper layer will queue up more retransmissions faster than the lower layer can process them. This makes the upper layer TCP connection stall very quickly and every retransmission just adds to the problem—which can lead to an internal meltdown for the entire system. As a result, the current implementation of application data flowing on a TCP-over-TCP connection is not graceful and could fail when the network is busy or slow with respect to the TCP timer values.